Generally, an Advanced Metering Infrastructure (AMI) may contain up to millions of metering devices distributed over a large geographical area. Such devices are typically configured to exchange messages including data, for example, utility consumption data, with a cluster of servers including data metering collectors, and network management servers. AMI environments are generally organized around Autonomous Systems (AS) headed by cell relays (sometimes referred to as cell routers), where each AS is connected by way of a back-haul network to servers that may be located at a utility home-office or other central location.
Those of ordinary skill in the AMI art will appreciate that the logical infrastructure interconnecting the metering devices or endpoints and the cell relays/routers is frequently based on a tree topology, on top of, for example, a wireless mesh network or a wired network, such as using power lines.
Typically, the nodes forming the AS can be classified into two broad classes of devices or nodes, with respect to the resources available at each respective device/node. Such broad classes include full functionality nodes/devices and reduced functionality nodes/devices. Full functionality nodes are devices that typically have relatively large memory space and high processing power, while reduced functionality nodes correspond to devices that typically have relatively smaller memory space and lower processing power.
One of the main challenges for routing in an AMI network with reduced functionality nodes is the implementation of an efficient routing scheme. The resource constraints of such nodes make the storing and maintenance of large routing tables a practical impossibility. Eventually, such nodes often maintain a greatly reduced or “lite” routing table with routes toward a very few of their one-hop neighbors. Typically, such nodes only store information about their one-hop upstream neighbors, sometimes called their parents. In such context, it should be appreciated by those of ordinary skill in the art that storing in such nodes more detailed routing information to reach neighbors that may be several-hops away is very challenging.
In frequent cases, the only node within an established tree that has a global view on the network may be what is referred to as the root of the tree. The root has enough resources to accommodate detailed routing information and maintain route/routing information to each node within the tree. As those of ordinary skill in the art will appreciate, path computation towards each node can in straightforward fashion be implemented using known techniques once the root has detailed knowledge on topology and available links.
The routing schemes in such tree topologies are typically organized around two kinds of flows: upstream flows and downstream flows. Upstream packets flow from tree leaves up to the root of the tree (multipoint to point), while downstream packets flow from the tree root towards the leaves (point to multipoint). Upstream messages are always destined for the root of the tree, while downstream messages can be destined to any of the tree nodes.
Upstream routing is simple in that each node (even reduced functionality nodes that have at least one entry in their routing table for upstream neighbors that receives a message destined for the root simply forwards it upstream to its one-hop neighbor (parent). Downstream routing uses a source routing approach. That is, the root of the tree inserts the explicit route information, including all the addresses of the intermediate nodes/hops between the source and the destination of the message, into the header of a downstream packet. Here, each intermediate node that receives a packet inspects the routing header of the packet (which is a list with the complete path), processes and consumes/removes the header containing its address, and further forwards the packet to the next-hop on the list.
As is understood by those of ordinary skill in the AMI art, intermediate nodes do not need to store tables listing their downstream neighbors because wireless networks are a broadcasting domain so that a unicast message transmitted by a node is inherently heard by all of its neighbors. Such person of ordinary skill in the art will also appreciate that source routing is not an issue for such hardware-constrained nodes, and that end-to-end reliability can be achieved by deploying one-hop retransmission mechanisms, at link-layer, as well as end-to-end retransmission mechanisms at higher layers.
As may be seen, within an AMI environment communications between endpoints (that is, for example, metrology devices) and a tree root (or more generally a central facility that may be generally designed to collect data from the various endpoints) is a fairly straightforward process. More recently, however, there has been expressed increasing interest in providing communications capabilities between peer devices for providing such features as demand response and automation communications. It would be advantageous, therefore, to provide efficient peer-to-peer communication capabilities between the nodes of the tree, when the source and destination of such communications are presumptively not the root of the tree. Using only previously known routing mechanisms, the tree nodes cannot set-up peer-to-peer communications directly. That is, peer-to-peer communications between nodes that are not roots must per the current state of the art be routed nonetheless via the root of the tree. As such, it would be advantageous to provide improved routing capabilities that would provide peer-to-peer routing optimizations for advanced metering infrastructure applications in an open operational framework.
While various aspects and alternative embodiments may be known in the field of AMI routing, no one design has emerged that generally encompasses the above-referenced characteristics and other desirable features associated with peer-to-peer communication technology as herein presented.